W701. The catalog gate applied the GoldenFloat generating rule

    e = round((bits - 1) / phi^2),  m = bits - 1 - e

to every record labelled `cluster=GoldenFloat`. That cluster holds four families
on two axes, and 41 of the gate's 43 findings were the rule being applied to two
of them.

THE RECORDS SAY SO THEMSELVES, in the field the gate parses:

    bnf8   standard="... control for TNF8; width rule 1+E+M=N;
                     exponent sized for range not phi"
    tnf8   standard="... e is 3 balanced-ternary TRITS not bits (4.75 bits
                     equivalent); width rule 1+Et+M=N"
    gft8   standard="... GOLDEN RATIO axis: E_t = round((N-1)/phi^2)"

So the split is the data's, not mine. The file's own prose says it too, ten lines
above the flagged rows: "NOT the golden-ratio family ... Four formats, two axes."

And the numbers corroborate it twice over. Every bnf/tnf catalog e and m equals
the constants in the spec its `source=` names -- 17 of 17. Every bias is a closed
form of that same e: (3^e-1)/2 for tnf and gft, 2^(e-1)-1 for bnf, 22 of 22. A
mistyped exponent would strand its bias; none is stranded.

WHAT CHANGED. The three phi checks now run where a record declares
`rule=phi-ratio`, added to 30 records. A GoldenFloat-cluster record without one is
COUNTED and named in a single loud finding -- a skip nobody counts is the shape
this gate exists to refuse.

`tnf8` satisfies the phi rule and is deliberately NOT marked. At 8 bits the
range-sized and phi ladders coincide; encoding a coincidence at one width as a
design decision is how a catalog acquires a second wrong rule.

    catalog gate   109 records, 43 findings, 42 unexpected
                -> 109 records,  3 findings,  2 unexpected
    GATE FAILURES  42 -> 2, and the ratchet demanded the re-bless:
                   "GATE FAILURES fell 42 -> 2 (-40) -- re-bless to pin"

The two that remain are real: `getter-parity` (109 records, 83 getters) and the
new `gf-rule-unstated` (17 records naming no rule).

FOUR CORRECTIONS TO MY OWN FIRST READING, from an adversarial audit run against
it. I had said: 42 findings (it is 43, of which 42 unexpected); zero findings on
gf*/gft* (gfternary does produce one, from a different check); two families (the
repository's taxonomy is four on two axes); and that bnf/tnf e-values "do not look
rule-derived at all" -- they are derived, by a documented rule that is not this
one. My logarithmic curve-fit was a red herring: the rule is "size the exponent
for the range, then 1+E+M=N".

AND ONE FINDING I WAS WRONG TO DISMISS. `tnf16` records phi_distance=0.086, which
is the value for m=9; the record and its spec say m=11, which gives 0.0417. It is
genuinely stale under the catalog's own convention -- flagged by the gate for the
wrong reason, but flagged. Not corrected here: it is the owner's numeric data and
this commit changes classification only. Filed separately.

    cargo test --no-fail-fast     2437 passed, 0 failed
    suite --ratchet               RATCHET: CLEAN, exit 0
    check_catalog_integrity.py    exit 0
    check_catalog_count.py        exit 0
    check_seal_coverage.py        exit 0 (catalog re-sealed)
    check_specs_generate.py       exit 0
    check_elab_ratchet.py         exit 0
    parse-conform                 24/24

Refs #2762

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…d changed

The withdrawn-number baseline is keyed by sha1 of the normalised line, BY DESIGN
-- its own header says "editing the line re-opens the gate, which is what we
want". Adding `rule=phi-ratio` to the gf16 CATALOG record edited that line, so
the gate re-opened and asked for the line to be re-confirmed.

Re-confirmed: the line still reads "323 MHz withdrawn, see RESEARCH_CLAIMS.md".
It is text ABOUT the retraction, not a live claim, exactly as before. One entry
re-keyed by hand rather than regenerating the file, so no other drift can ride
along.

I first computed the key from the raw line and got a hash the tool did not
recognise -- it normalises whitespace before hashing (`" ".join(line.split())`).
Reading how the key is MADE, not just what it looks like, is the difference
between a green gate and a second wrong hash.

    check_withdrawn_live.py   exit 0

Refs #2762

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

…cope-v2